Context for this PR:

This PR is a re-implementation of HarmonyOS platform support based on the latest main branch.

I previously submitted an initial version in #613, but that was based on an older main branch (roughly 89 commits behind). During that period, the main branch evolved
significantly with major refactors to core files like capabilities.ts, dispatch.ts, and cli-flags.ts, making a direct rebase impractical due to massive conflicts. I chose to
create a fresh branch from the latest main (6946c2f) and migrate the HarmonyOS support code file by file.

Both versions implement the same feature set, but this version:

• Targets the latest type system and architecture
• Fixes the incomplete keyboard action enum issue left in feat: add HarmonyOS platform support #613
• Adds install / reinstall support
• Adds fill text verification and push notification support
• Updates the help system with the help harmonyos topic

If maintainers previously reviewed #613, the core platform implementation logic (under platforms/harmonyos/) remains essentially unchanged — this is primarily an adaptation to the
latest interfaces and types. The old PR #613 can be closed.

Thanks for the contribution. This is a big piece of work, and directionally the approach looks right to me: HDC as the transport, uitest dumpLayout / uiInput for snapshot + input, aa for ability launch, and bm for app inventory/install all line up with the HarmonyOS/OpenHarmony docs I checked.

I found a few things that I think need fixing before we can land this:

1. pnpm check:quick currently fails on a duplicate import in src/platforms/harmonyos/snapshot.ts (../../utils/snapshot.ts is imported twice). Typecheck passes, but lint blocks CI.

2. record is marked as supported for HarmonyOS in src/core/capabilities.ts, but the daemon recording path is not wired for HarmonyOS. In record-trace-recording.ts, non-iOS/macOS devices fall through to startAndroidRecording, so record start --platform harmonyos will try the Android/ADB path instead of the new HarmonyOS recording helpers.

3. settings permission deny ... --platform harmonyos looks wrong: setHarmonyPermission parses grant|deny|reset, but both grant and deny currently execute bm grant-permission. If deny is not supported yet, I think we should reject it explicitly instead of silently granting.

4. The typed Node client normalization needs HarmonyOS fields. The daemon returns bundleName for HarmonyOS install/reinstall, but normalizeDeployResult only reads bundleId / package, so apps.install() / apps.reinstall() lose appId. normalizeOpenDevice also rejects platform: "harmonyos", so apps.open() loses device metadata for HarmonyOS sessions.

5. There is a likely typo in the locked-screen fallback: app-lifecycle.ts uses uitest ui-input swipe, while the rest of the implementation and the docs use uitest uiInput.

Validation I ran:

• pnpm typecheck passes
• pnpm exec vitest run --project unit src/platforms/harmonyos passes: 6 files, 20 tests
• pnpm check:quick fails on the duplicate import above

I also tried to validate locally. I have DevEco Studio installed on macOS/Apple Silicon; bundled hdc works outside the sandbox and reports Ver: 3.1.0e, but hdc list targets returns [Empty]. I can see the DevEco emulator binary, but I do not have a local HarmonyOS emulator image/device configured.

Could you share the exact steps you used to install/create a HarmonyOS emulator on macOS? A DevEco menu path is fine, but a CLI-friendly flow would be even better if one exists. That would help us verify this against a real emulator in addition to the physical-device testing you already did.

@thymikee

To use the HarmonyOS emulator, follow these steps:
Launch DevEco Studio My version is 6.0.2 Release
In the top-right corner of the IDE, click No Devices, then choose Device Manager.
In Device Manager, click New Emulator in the bottom-right corner and follow the wizard to create the emulator.

I need some time to review the other 4 bux.

Re-checking this PR today: it is currently blocked by merge conflicts (mergeStateStatus: DIRTY, mergeable: CONFLICTING) and there are no fresh checks reported for the current head. The earlier review feedback appears to have follow-up commits, but the branch needs a rebase onto current main before we can trust CI or finish review.

Please rebase, resolve conflicts, and rerun at least pnpm check:quick plus the focused HarmonyOS unit tests. After that I can re-review the remaining platform behavior against the current architecture.

Thanks for this substantial contribution, @wz9527 — adding a whole new platform is a lot of work, and the integration here is unusually disciplined for a first-pass new-platform PR. The shared-infrastructure edits are almost entirely additive, the exhaustive assertNever switch was updated correctly, and the new hdc layer mirrors the existing adb-executor AsyncLocalStorage/override pattern faithfully. Below is a regression-focused review with the existing platforms (iOS/Android/macOS/tvOS/web) as the lens.

Regression risk: Low. Shared-file changes are additive branches guarded by device.platform === 'harmonyos'; no existing iOS/Android/macOS/linux code path is altered in behavior, no runtime deps were added, and the one modified existing test (src/utils/__tests__/args.test.ts:4207) only updates the expected --platform enum string. The residual risk is conflict-resolution churn, not logic.

Needs rebasing (required)

This PR is CONFLICTING/DIRTY against main. It edits high-traffic shared files — src/core/capabilities.ts, src/core/dispatch.ts, src/contracts.ts, src/core/interactors.ts, and several src/daemon/handlers/* — which is exactly where recent main work landed (command-family facets, runner command traits, daemon HTTP contract helpers). Notably the PR edits src/client-output.ts, but on current main that logic now lives in src/commands/system/output.ts — a clear sign the branch predates the refactor. Please rebase on main and re-run the type-check before re-review.

Blocking

• src/commands/client-output.ts:141 (now src/commands/system/output.ts on main) — wrong field name. The new HarmonyOS formatAppState branch reads data.bundleId, but AppStateCommandResult (src/client-types.ts:456) has no bundleId field — the existing iOS/Android branches use data.appName ?? data.appBundleId and data.package. After rebase this is either a TS error or silently renders Foreground app: unknown. Fix: use data.appName ?? data.appBundleId.
• record advertised as supported but the implementation looks Android-shaped. src/core/capabilities.ts:404 enables record for harmonyos: HARMONYOS_DEVICE, but src/platforms/harmonyos/recording.ts:3676 shells out to screenrecord …, which is the Android binary; HarmonyOS capture is snapshot_display (used correctly in screenshot.ts). The PR's tested-commands table also doesn't cover record. Either verify screenrecord exists on HarmonyOS NEXT, switch to the supported capture path, or gate record off (harmonyos: {} + supports) like boot/logs/network/perf until validated — advertising an unsupported command violates the explicit-rejection convention.

Non-blocking

• src/core/capabilities.ts:250-253,264-268,314-315 — dropped rationale comments. The rebase incidentally deletes several "why" comments on alert, pinch, and keyboard (e.g. the iOS-simulator-only pinch synthesis note). These document non-obvious gating for the existing platforms; please restore them while resolving conflicts.
• src/platforms/boot-diagnostics.ts:1119-1146 — dead HarmonyOS branch. boot is correctly gated off for HarmonyOS in capabilities, so the HDC_TRANSPORT_UNAVAILABLE classification path is currently unreachable. Harmless/defensive, just noting it.
• Missing timeouts on basic input actions. pressHarmony/swipeHarmony/typeHarmony/pressBackHarmony in src/platforms/harmonyos/input-actions.ts call runHarmonyHdc without timeoutMs, so they're unbounded if hdc hangs. This matches existing Android runAndroidAdb practice (not a new-platform deviation), and the probe/dump calls do set 10s timeouts — but a default timeout would be a nice hardening follow-up for both platforms.
• Snapshot fast-paths skip HarmonyOS. The ios/android freshness + overlay optimizations in src/daemon/handlers/snapshot-capture.ts (~lines 109-115) won't apply to HarmonyOS, which routes through the generic interactor snapshot(). Correct and safe — just a missed optimization, not a defect.
• Good call adding the perf capability guard in src/daemon/handlers/session-observability.ts:1014 and routing everything through the Interactor facet + getInteractor switch rather than special-casing dispatch. The parser unit tests (__tests__/app-parsers.test.ts, arkui-hierarchy.test.ts) are exactly the right surface to cover.

Overall: convention-compliant and low-risk to existing platforms. The two blockers are HarmonyOS-local correctness issues plus the mandatory rebase — no cross-platform regression. Nice work.

_{🤖 Automated review via Claude Code}

When can it be integrated and the official version be released?

Still need to hook the simulator (have the device), will get to it soon hopefully!

@wz9527 👋 Just checking in — any update on this? The maintainers have left some feedback and it seems things have gone quiet. Would you still be planning to address them, or would you be open to someone else picking this up?